四层不是架构图，是四份契约

每一层向上交付一样东西，下一层才能接得住。

整套方案自下而上分为四层：数据接入、治理合并、指标中心、应用呈现。理解这个分层，就理解了这套方案为什么能把"问数"这件事当天闭环。

图 1　金蝶云星空 AI+BI 标准方案整体架构

这四层不是常见的"技术架构图"画法——把一堆组件按高低摆一摆。它真正的含义是四份契约：每一层向上交付一样东西，下一层才能接得住。整条链路能跑通，靠的是契约对齐，而不是某一层做得特别漂亮。

层级

核心职责

向上交付的契约

破坏契约的后果

第一层：数据接入

把云星空的数据完整、准时搬出来

抽取契约

上层拿到脏数据，所有分析都不可信

第二层：治理合并

集团多账套统一口径

合并契约

合并数对不上，管理层不敢用

第三层：指标中心

让"数"只有一个口径

口径契约

三套数并存，汇报先争论口径

第四层：应用呈现

看板、驾驶舱、报表、财务分析

呈现契约

图画得再漂亮，问不到就白搭

下面逐层拆开，每一层都讲清楚三件事：具体做什么、交付什么、以及哪些细节最容易被做错。

一、第一层：数据接入——把云星空的数据完整、准时搬出来

云星空的数据分布在财务会计、供应链、库存、生产制造、销售、售后等多个业务域，标准方案通过数据集成平台按业务域建模抽取。

全量加增量结合

主数据与组织架构走全量同步，业务单据按更新时间戳增量抽取，避免全量跑批压垮生产库。

主数据和业务单据必须分开处理，因为两者性质不同。主数据变化频率低，但每次变化都会影响大量历史单据的解释——物料改了名称，历史单据显示的名字也要跟着变，所以必须全量同步并保留变更历史。业务单据数据量大、变化频繁，全量跑批的问题不只是慢，更在于会在业务高峰期占用生产库资源，影响正常开单过账。

统一落库规范

按"主题域—数据域—实体"三级组织模型落库，财务凭证、销售订单、生产工单各自成域，但共享统一的组织、往来单位、物料、客户等公共维度。

这套结构的价值在于：不同业务域可以互相拼接，同时各自保持业务语义。当要回答"华东区某客户回款周期为什么变长"这类问题时，需要把销售订单、客户档案、收款凭证、账龄表串起来——只有当这几个域共享同一套维度编码，串联才成立。

数据质量校验

同步完成后自动做行数比对、金额勾稽、关键字段空值检查，异常自动告警，避免"报表没数"或"数对不上"。

行数比对回答"有没有少"，金额勾稽回答"有没有错"，空值检查回答"能不能用"。三者合起来，拦下的正是最常见也最难排查的两类问题。

这一层最容易做错的三件事

第一，用全量跑批接业务单据。第一次抽取就把生产库跑满，项目会被业务部门叫停。

第二，跨域维度编码不统一。财务域用客户编码 A、销售域用客户编码 B，哪怕名称一样也无法关联。这是企业自建报表最耗时的部分——手工做主数据对照表。

第三，跳过质量校验。校验不是附加功能，是省钱工具。排查一个"数对不上"，代价可能是几天的比对与口径回溯；自动校验在同步完成的那一刻就把问题暴露了。
二、第二层：治理合并——集团企业的第一道坎

多组织、多账套、多币种企业做云星空多账套合并，难点不在技术实现，而在三条规则必须提前定死。

规则一：科目与组织映射

不同账套的科目体系、辅助核算维度不一致，需要建立统一映射表，把各账套科目归集到集团标准科目，否则合并口径永远对不齐。

现实中的差异往往比想象大：集团 A 账套把"销售费用"拆成"运费""佣金""推广费"，B 账套只设一个"销售费用"靠辅助核算维度区分，C 账套则把运费直接计入"主营业务成本"。同一笔业务，在三个账套里落在完全不同的科目上。

映射关系是多对多的，不是简单的一对一。这决定了映射表本身需要财务确认，也决定了表里必须保留空行位——某账套本期没发生额，不代表它在标准科目体系里不存在。

辅助核算维度的差异同样要处理。A 账套按"部门 + 费用类型"两个辅助核算，B 账套只按"部门"，合并时必须明确统一到哪一侧、以哪一侧为准。

规则二：内部交易抵销

集团内关联交易必须互抵，否则合并收入虚增。方案支持按往来单位、物料、期间做内部交易识别与抵销，抵销过程可追溯到每一笔原始单据。

识别内部交易的基础是"交易双方都在集团范围内"——所以集团组织范围清单本身就是合并规则的一部分，哪些组织算内部、哪些算外部必须明确声明。

匹配要靠三个维度组合：往来单位（同一客户既买又卖）、物料（同一物料在集团内流转）、期间（同一笔交易在两个账套的确认时间是否一致）。三者齐备，识别准确性才够。

期间差异是最容易漏的一环。A 账套 12 月确认销售、B 账套次年 1 月确认采购，这笔内部交易在 12 月合并里对不上，差额会跑进"未确认内部交易"科目。成熟方案会做跨期匹配与暂估抵销，而不是让差额自然沉淀。

"可追溯到每一笔原始单据"这五个字是验收标准：要能回答合并表里这行抵销金额由哪几笔内部交易构成、匹配依据是哪个维度、时点差异怎么处理。答不上来，就是黑盒——而抵销恰恰是合并报表中最容易被审计追问的部分。

规则三：多币种与折算

外币账套按即期汇率或期末汇率折算，汇率来源与折算方式需在指标层明示，避免出现"合并数没人敢认"的局面。

两个关键决策：用即期还是期末汇率。损益类项目通常用即期（或期间平均）汇率，资产负债表项目用期末汇率，两种方法出来的利润数不同，必须写死。汇率从哪来也要明确——财务维护的月度汇率表，还是财务系统的自动折算结果？两个来源并存而不指定优先级，同一笔外币业务会在不同报表里折出两个数。

规则必须写在指标层——因为指标层是所有报表的共同来源。写在某个 Excel 里，就意味着只有那一张表是对的。

合并完成后，集团层与各事业部层的数据可以同屏呈现：既看得到集团整体毛利，也能一键下钻到某个账套、某个工厂的明细。

三、第三层：指标中心——让"数"只有一个口径

指标中心是整套方案的中枢，也是金蝶云星空报表与经营分析能否被老板信任的关键。

指标分层

原子指标（销售额、毛利额）→ 派生指标（毛利率、费用率、周转天数）→ 复合指标（人效、库存健康度、现金周期）。

分层的意义在于可组合。复合指标不是硬编码的公式，而是由底层原子指标按规则组合而成——人效 = 毛利额 ÷ 人数，两个原子指标的口径一旦确定，人效的口径就自动确定。

口径固化

每个指标绑定唯一定义，包含计算公式、维度、过滤条件、数据来源与责任人；改动需走版本管理与审批，历史数据不被悄悄改掉。

"历史数据不被悄悄改掉"这半句最容易被忽略，却是财务最在意的地方。毛利率的定义从"含运费"改成"不含运费"，如果直接改掉定义，昨天的经营报表和今天的就对不上了，历史趋势图会悄悄变形。正确的做法是发布新版本，旧版本保留，历史期间按当时口径复现——审计和年度对比都依赖这个能力。

单一事实来源

一个指标在看板、报表、AI 问答、财务分析中永远取自同一定义，彻底消除"财务算一套、BI 算一套、业务又算一套"的三套数。

这句话的实际检验方法很直接：把同一个指标分别从看板、报表和 AI 问数里各调一次，三个数必须完全一致，且都能点开看到口径定义与原始明细。做得到，数据资产才算立住；做不到，上层做得再好也是空中楼阁。

权限与行级安全

指标可按角色、账套、组织授权到人，敏感财务数据在指标层即完成隔离。

在指标层隔离而不是在报表层过滤，是这一层与上一版做法的重要差别。报表层过滤意味着每个人看到的其实是同一张全量报表，只是前端不显示——数据仍然在权限之外。指标层隔离是数据本身就被切开，越权取数在源头就走不通。

四、第四层：应用层——看板、驾驶舱、报表与财务分析

看板（Dashboard）

面向业务部门的日常监控页，按角色装配，支持大屏与 PC 双形态，指标可下钻到明细单据。

看板解决的是"发生了什么"。按角色装配是关键——销售看自己的看板，财务看自己的看板，不需要在一张图里做权限区分。

经营驾驶舱

面向老板与高管的一屏总览。看板回答"发生了什么"，驾驶舱回答"所以呢、怎么办"，它把经营目标、实际达成、差异归因、改进建议串成一条逻辑链。

这两个概念的区分在实践中很重要。做驾驶舱最常见的失败方式，是把各个部门的看板拼到一页——那是一面数据墙，不是一条决策链。真正的驾驶舱要在看现状、看差距、看归因、定动作之间形成闭环。

金蝶云星空报表

与云星空标准报表体系对接并扩展，月度经营报表、成本分析表、销售汇总表等支持定时生成与推送。

这一项的价值是不破坏已有习惯。企业已经在用云星空标准报表，方案是叠加而非替换，标准报表继续可用，BI 负责承载经营分析与自定义场景。减少推行阻力，比多几个功能更重要。

财务分析

费用结构、盈利分析、资金与现金流、应收应付账龄、三表联动分析，天然支持多账套合并口径。

"天然支持多账套合并口径"这几个字是第二层工作到位之后才成立的。费用结构要按集团标准科目归集，三表联动要在统一模型上跑——这些的前提都是合并层已经把口径对齐了。

对接 BI

奥威 BI 引擎向上兼容，方案既可作为独立 BI 平台使用，也可将驾驶舱与看板以嵌入方式挂载回金蝶云星空门户，用户在 ERP 里直接看数，登录态与组织权限沿用同一套。

嵌入回云星空这一点解决的是使用路径问题。员工每天开云星空处理业务，驾驶舱挂在 ERP 门户里，不需要再多开一个系统、不需要再记一套密码、不需要为"用不用 BI"专门做推广。能让分析工具出现在工作流里，比让分析工具更强大更重要。

一个最容易忽略的判断标准

如果一家企业的 BI 项目反复出现"口径又要重对一遍"的情况，问题往往不在报表层，而在于第一、二层的契约没有真正交付——接入给的不是统一维度的数据，合并给的不是可追溯的结果，指标层只能自己兜底。

五、四层之间到底怎么衔接

把四层看成一份契约链，每个交接点都有明确的交付物与验收方式。

交接点

上一层交付

下一层验收

接入 → 合并

统一的组织、物料、客户等公共维度

跨域能否直接关联，无需手工对照

合并 → 指标

归集到标准科目的合并数据

合并毛利能否与财务系统对上

指标 → 应用

唯一定义 + 权限标签的指标

四个应用取同一个指标，数值是否一致

三条验收线，任何一条不通过，问题就会在后面被放大。

最典型的例子是第二条：合并毛利对不上财务系统，问题不会停在合并层，而是往上冒——到指标层变成"这个毛利率算得不对"，到应用层变成"报表和财务系统对不上"，最后变成"财务拒绝在经营会上用这套驾驶舱"。根因在第二层，症状在第四层。这就是为什么要按层验收，而不是等到管理层面前才发现。

六、落地顺序：不要跳层

四层架构最常被违反的方式，不是某一层没做好，而是跳层推进。

最典型的跳层有两种：一种是指标中心还没定口径，就先上大屏驾驶舱——页面做得很漂亮，但每个数字的口径都在变，最终无人敢用；另一种是合并规则还没定，就先做跨账套报表——财务不认这个数，看板就停在验收环节。

正确的顺序是自下而上，但每层都要留出"可见的价值"给业务看。数据接入阶段可以先交付数据质量报告与账套清单，让业务看到底数；合并阶段可以先交付合并对照表，让财务先验数；指标阶段可以先交付几个核心指标的口径文档，让管理层确认定义；最后才是驾驶舱与问数的完整交付。

这样每一步都有阶段性成果，推行阻力小，出问题也容易定位在哪一层。

七、常见问题快答

四层架构是不是必须一步到位？不是。可以先做第三层和第四层的一个小子集，比如先固化 20 个核心指标加一个经营驾驶舱，但第一、二层的基础规范不能省——省掉的部分会以上层返工的形式还回来。

企业只有单账套，可以跳过第二层吗？可以。但"跳过"不等于"不设规则"——至少要明确集团组织范围与标准科目，为将来的多账套留好接口。

指标中心要建多少指标？建议从 30 至 50 个经营指标起步。这不是越多越好：指标数量超过一两百个之后，维护成本会超过收益。关键是先覆盖管理层真正关心的那几件事。

看板、驾驶舱、报表、财务分析要同时上吗？不必。标准做法是先上三个高频场景——经营驾驶舱、财务分析看板、AI 问数，用真实问题压测。

版本升级会不会影响已有指标？指标中心保存的是业务定义与数据来源映射，不是针对某个版本的表结构硬编码。版本升级的适配由方案方承接。

结语

四层架构看上去是一张图，实际上是一份责任划分：数据接入对"准"负责，治理合并对"对"负责，指标中心对"一"负责，应用呈现对"有用"负责。

四层各司其职、层层交付、不可跳级，是这套方案能把"问数"当天闭环的根本原因——不是因为某一层用了 AI 或多做了几个图，而是因为从数据进来到答案输出，每一步的产出都恰好是下一步需要的输入。

老板问"上个月到底赚了多少钱"，系统在当天给出一个和财务账对得上、且能一路点到原始单据的答案——这件事看起来是一个技术成果，实际上是四份契约全部对齐的结果。